A cache memory is fast memory that resides logically between a microprocessor and main system memory. The purpose of cache memory is to speed up memory access. A cache memory is typically small relative to main memory because it consists of relatively expensive memory modules. If all of a main system memory could be constructed out of the same fast memory used for cache memory, there would not be a need for a cache memory. Cache memory is therefore an efficient, cost-effective way of using a small amount of very fast memory to optimize overall memory access speed.
Management logic within a cache memory controller coupled to the cache memory keeps track of data most recently accessed from main memory and keeps those data locally in the cache memory. To accomplish this, the cache memory controller employs a directory to tag each datum within the cache memory as having or not having been read. This directory allows the cache memory controller to determine when new data should be read from main memory into the cache memory. For different architectures of cache memories, the data may reside only in the cache memory, or it may reside both in the cache memory and in main memory.
When using a cache memory within a computer system, there is a need to determine the size of (commonly referred to as "sizing") the cache memory prior to testing the cache memory with a diagnostics routine. Sizing a cache memory is an involved process, since it is difficult to determine if the processor is accessing an element that is in the cache memory or if the processor is actually accessing main memory, because a quickly-responding read from main memory appears to the processor similar to a cache memory read.
Prior art methods for discerning differences between a cache memory access from a main memory access have used timing methods. Generally, an access to cache memory is faster than an access to main memory. However, timing is awkward when the diagnostics routine is embedded, rather than disk-based, since there are a multitude of different speeds of processors that can reside in the system and, if the diagnostics routine does not use software timing loops, the routine must rely upon hardware-based system timers, producing added hardware dependencies.
There are several types of cache memory management techniques employed in cache memory controllers. One technique is direct-mapping, wherein the cache memory operates in a linear address space. Within a direct-mapped cache memory, there is a single unique location in the cache memory where a piece of data may reside. Another technique is multi-way (or "X-way") set association, wherein the cache memory consists of a number of pages (each page is termed a "way") of address space so, for a given address in main memory, that address could reside in any one of several places within the cache memory.
For example, in a four-way set associative cache memory, any address in main memory could reside in one of four locations in the cache memory. There is an advantage to this configuration for software that performs nonsequential operations (such as addressing operations that jump back and forth between noncontiguous pieces of the address space). For example, if addresses A and B have the same address offset in the cache memory, in a direct-mapped cache memory, if the processor is repeatedly accessing locations A and B in the loop very rapidly, then these locations will continuously replace each other within the cache memory, and the cache memory is not going to yield a satisfactory performance advantage. However, in an X-way set associative cache memory, if two locations with the same offset are being repetitively called and accessed, those two locations can simultaneously exist in the cache memory without replacing each other, and the cache memory delivers greater performance benefit to the system.
For a cache memory sizing algorithm to be most useful, it should size the cache memory each time diagnostics routines are executed, prior to cache memory static random access memory ("SRAM") and cache memory controller tests. The cache memory sizing is performed each time the diagnostics routines are executed because: (a) the actual cache memory hardware may have been physically replaced with a different size cache memory, or (b) the cache memory hardware may have become faulty since the last time it was tested.
Cache memory sizing may also be employed as a form of error detection, and not just a prerequisite to the diagnostics. In other words, if access is available to a hardware configuration setting in the system that indicates how large the cache memory should actually be, then a comparison of the cache memory size detected by the sizing algorithm with the hardware configuration can lead to the immediate detection of faults. For example, if some hardware configuration setting indicates that the cache memory should be 128 kilobytes ("K") in size and the software cache memory sizing procedure indicates the cache memory is only 64K, then the system should prompt the user to the discrepancy before proceeding to other cache memory tests at that point.
Sizing the cache memory is necessary because subsequently-employed cache memory testing routines need to fill the entire cache memory space with data patterns and perform accesses to thereto. In the past, sizing of the cache memory has been accomplished by firmware and software via some kind of hardware indicator, especially basic input/output system ("BIOS") firmware. BIOS firmware is very hardware-specific, therefore it can make assumptions about the type of system it is running on, e.g., it can recognize that there is a cache memory controller type "A" in a particular system and, with this particular manufacturer's controller, there are data in the controller's addressable memory that indicate the size of the cache memory. Because it is aware of the target hardware, BIOS can look at hardware indicators and specify the size of the cache memory.
The same procedure is typically performed with a disk-based diagnostic. The diagnostic identifies the particular type of system that it is executing upon and then, via table look-up, determines what type of cache memory controller is used within the system and then looks at a hardware indicator that specifies the size of the cache memory.
However, there is not a known firmware or software method that dynamically sizes a cache memory. An advantage to dynamically determining the size of the cache memory is to have a generic piece of firmware that can identify the cache memory without having to rely on hardware indicators. The code thus becomes more portable and more flexible. As an example, embedded diagnostic codes are built for a particular type of system that is produced with one size of cache memory. At some later date, one or more larger sizes of cache memories may be added to this system. However, it is unknown what the hardware indicators will look like, i.e., the data that specify the size of those cache memories, since that logic has not yet been configured at the time the original code is designed. Therefore, a problem arises once those additional larger sizes of cache memories are built, since the original diagnostics code will have to be modified to accommodate the larger cache memories. This is a concern because the diagnostics code has been previously embedded in firmware in the user's system, yet that firmware must be adaptable to user-installed increases in cache memory. An upgrade of the diagnostics code in the field would be required if a larger cache memory than the diagnostics code could handle were employed. Thus, a flash diskette and a BIOS and diagnostics code upgrade would have to be sent to the user along with the upgraded cache memory.
Accordingly, what is needed is a dynamic procedure that will size a cache memory completely independent of the type of cache memory controller and cache memory management technique employed.